sasecurityfandomcom-20200214-history
TcpDump
Category:Sasecurity back to http://scratchpad.wikia.com/wiki/Sasecurity TableOfContents should have been 'tcpdump' > have you tried using > tcpcump -i wlan0 tcp > or > tcpdump -i eth0 tcp > on the node, to double check if the box is being flooded with traffic in some way? Instead of leechtest, you can also try downloading, using a wireless client, one of the large MeshAP images from LW's site http://www.mirror.ac.uk/mirror/live.locustworld.com/32mb-images/ They're large enough to give you speed indication. >>Hi, >>All we have a problem node, but not sure what happening. The node has 2mb backhaul, runs fine most of the time. This node has been great for over a year but of resent times it has become very slow. We have some repeater nodes running of this gateway node, which I can ssh in to from another GW, I can run speed tests via the slow node and get top speeds via the slow node. I can access the slow node's router at very fast speeds and ssh via remote gateway, but try to ssh to the slow node via its ethernet gateway feed and all comes to a stop. The node is not loaded, I can see this from the router QOS graph etc, its something to do with the node. The temp is normal and volts, not sure what can be causing this. Its 150ft up so we only want to go up once as its on a commercial site and we have to pay for site access, by the hour. Could it be memory? 128 mb fitted. VIA-500 board, senao radio, Fans are plugged in. --- Found out what is dragging the box down, we a user runs a VPN session (not to the box -outside vpn), it kills the mesh box, the qos on the router is doing its job but the mesh box seam to died under the a vpn connection, its fine with heavy web traffic VOIP and ftp, but VPN kills it! this is a pro node. sdfsdfsdf ed about this, as Kenny knows. Although -I've- never gotten technical answers here (it's supposed to be quid pro quo Jon), I will say that your tcpdump is telling you this is SSH traffic, and so it's just your own. To exclude your own traffic, try: tcpdump -qi {whatevertheinterfaceis} 'not port ssh' Note that if you use -i any , captures will not be done in promiscuous mode, which means only traffic actually through the node will be reported. Use -q, to suppress that timestamp hash junk. The first thing to figure out is whether he's on wire or on radio for that node. Assuming that there is someone leeching, determining how he does it may take a detailed knowledge of NoCatSplash. However I suspect it's something simple, like maybe they hijacked the gateway or are simply bypassing the portal. Blocking the MAC won't work; MAC authentication is *no* security. Does the offending MAC belong to *anyone* in wiana? (spoofing) Certificates would be best. Is directory indexing allowed on the node? IOW, if you remove the index.* file in a directory then surf there, will it list that directory's contents? It should give a "Directory Listing Denied", and if it doesn't, it's probably your problem; HUGE security hole. This is an option in the http server. I don't use LW, so don't know which server you're using, nor how to fix it. Do you really have a second interface? If not, set it to ad-hoc and that will disappear. This looks like your ssh traffic though.. not p2p. I don't see how someone can get on the network without a username, password, MAC authentication bypassing the captive portal. I've not personally used Meshtrak, but isn't it supposed to have many of the same features as LW Pro? If so, you should easily be able to determine who it is downloading p2p and shut that account down or change their method of access if it's been compromised. One other suggestion: I would consider upgrading to Pro software for just the reason you are writing this message! I had two access points on my network that were running OSS because they have only a couple of users and were fairly easy to watch after (and I like to experiment with OSS!). However, just last week I had two clients that had their M$ PC's hijacked by some mass-mailing email virus. Our mail server is actually located off the mesh, and it has Spam Assassin installed on it. Once our gateway IP was flagged as a spammer's IP, we were no longer able to send email out (on port 25) from our network (until we shut them down) since our own server was off the mesh! Fortunately I was able to track down the infected PC both times very easily because both were on MeshAP's running Pro software. Wiana flagged them as having several megs of traffic on port 25 and one guy sent 1,000,000 packets out on port 25 - which made him very easy to spot! Having this capability made me realize the importance of running Pro software on all of my nodes as this would have been very difficult to track down on OSS on a busy network and since then I've upgraded those two. > Using Meshtrak (www.meshtrak.com) I was able to see that one person > not authorized on my wiana realm has downloaded a gigabit of stuff > which looks like p2p. > > I see on the wiana topographical map that I have an interface > 10.11.15.20. I commented on this earlier and have seen it for quite > some time. You all said this was due to the second interface being set > to infrastructure mode. However, after doing a tcpdump, it seems that > someone has exploited this interface. Here is some tcpdump output. > ----------------------------------------------------------------------- > ---------------------- > 21:52:32.200301 1.34.49.152.ssh > 10.11.15.20.2349: P 49953:50129(176) > ack 48 win 9792 (DF) > 0x10 > 21:52:32.200311 1.34.49.152.ssh > 10.11.15.20.2349: P 50129:50305(176) > ack 48 win 9792 (DF) > 0x10 > 21:52:32.200322 1.34.49.152.ssh > 10.11.15.20.2349: P 50305:50481(176) > ack 48 win 9792 (DF) > 0x10 > 21:52:32.203115 1.34.49.152.ssh > 10.11.15.20.2349: P 50481:51105(624) > ack 48 win 9792 (DF) > 0x10 > 21:52:32.204135 1.34.49.152.ssh > 10.11.15.20.2349: P 51105:51297(192) > ack 48 win 9792 (DF) > 0x10 > 21:52:32.204852 1.34.49.152.ssh > 10.11.15.20.2349: P 51297:51489(192) > ack 48 win 9792 (DF) > 0x10 > 21:52:32.205572 1.34.49.152.ssh > 10.11.15.20.2349: P 51489:51681(192) > ack 48 win 9792 (DF) > 0x10 > 21:52:32.206287 1.34.49.152.ssh > 10.11.15.20.2349: P 51681:51873(192) > ack 48 win 9792 (DF) > 0x10 > 21:52:32.207035 1.34.49.152.ssh > 10.11.15.20.2349: P 51873:52065(192) > ack 48 win 9792 (DF) > 0x10 > 21:52:32.207763 1.34.49.152.ssh > 10.11.15.20.2349: P 52065:52257(192) > ack 48 win 9792 (DF) > 0x10 > 21:52:32.208483 1.34.49.152.ssh > 10.11.15.20.2349: P 52257:52449(192) > ack 48 win 9792 (DF) > 0x10 I dont know how they would be able to get through either. But I am getting logs from them on meshtrak and see their IP show up on wiana. Someone living near the node I see the traffic on had emailed me just prior to the "illegal" activity requesting an account. I hadn't heard back from them so I assume they got their internet. ;) Right now I have just added an iptables rule to DENY their mac address. We'll see if this solves any problems. I have determined the mac address but they dont have an account on wiana. This is what is confusing me. Meshtrak is free right now, LW Pro costs money. That is my primary motivation for using it, and I'm the developer ;). > Do you really have a second interface? If not, set it to ad-hoc and > that will disappear. This looks like your ssh traffic though.. not p2p. > > I don't see how someone can get on the network without a username, > password, MAC authentication bypassing the captive portal. I've not > personally used Meshtrak, but isn't it supposed to have many of the > same features as LW Pro? If so, you should easily be able to > determine who it is downloading p2p and shut that account down or > change their method of access if it's been compromised. > > One other suggestion: I would consider upgrading to Pro software for > just the reason you are writing this message! > > I had two access points on my network that were running OSS because > they have only a couple of users and were fairly easy to watch after > (and I like to experiment with OSS!). However, just last week I had > two clients that had their M$ PC's hijacked by some mass-mailing > email virus. Our mail server is actually located off the mesh, and it > has Spam Assassin installed on it. Once our gateway IP was flagged as > a spammer's IP, we were no longer able to send email out (on port > 25) from our network (until we shut them down) since our own server > was off the mesh! Fortunately I was able to track down the infected > PC both times very easily because both were on MeshAP's running Pro > software. Wiana flagged them as having several megs of traffic on > port 25 and one guy sent 1,000,000 packets out on port 25 - which > made him very easy to spot! Having this capability made me realize > the importance of running Pro software on all of my nodes as this > would have been very difficult to track down on OSS on a busy network > and since then I've upgraded those two. >> Using Meshtrak (www.meshtrak.com) I was able to see that one person >> not authorized on my wiana realm has downloaded a gigabit of stuff >> which looks like p2p. >> >> I see on the wiana topographical map that I have an interface >> 10.11.15.20. I commented on this earlier and have seen it for quite >> some time. You all said this was due to the second interface being >> set to infrastructure mode. However, after doing a tcpdump, it seems >> that someone has exploited this interface. Here is some tcpdump output. >> ----------------------------------------------------------------------- >> ---------------------- >> 21:52:32.200301 1.34.49.152.ssh > 10.11.15.20.2349: P >> 49953:50129(176) ack 48 win 9792 > 230252555> (DF) 0x10 >> 21:52:32.200311 1.34.49.152.ssh > 10.11.15.20.2349: P >> 50129:50305(176) ack 48 win 9792 > 230252556> (DF) 0x10 >> 21:52:32.200322 1.34.49.152.ssh > 10.11.15.20.2349: P >> 50305:50481(176) ack 48 win 9792 > 230252557> (DF) 0x10 >> 21:52:32.203115 1.34.49.152.ssh > 10.11.15.20.2349: P >> 50481:51105(624) ack 48 win 9792 > 230252557> (DF) 0x10 >> 21:52:32.204135 1.34.49.152.ssh > 10.11.15.20.2349: P >> 51105:51297(192) ack 48 win 9792 > 230252557> (DF) 0x10 >> 21:52:32.204852 1.34.49.152.ssh > 10.11.15.20.2349: P >> 51297:51489(192) ack 48 win 9792 > 230252557> (DF) 0x10 >> 21:52:32.205572 1.34.49.152.ssh > 10.11.15.20.2349: P >> 51489:51681(192) ack 48 win 9792 > 230252557> (DF) 0x10 >> 21:52:32.206287 1.34.49.152.ssh > 10.11.15.20.2349: P >> 51681:51873(192) ack 48 win 9792 > 230252557> (DF) 0x10 >> 21:52:32.207035 1.34.49.152.ssh > 10.11.15.20.2349: P >> 51873:52065(192) ack 48 win 9792 > 230252557> (DF) 0x10 >> 21:52:32.207763 1.34.49.152.ssh > 10.11.15.20.2349: P >> 52065:52257(192) ack 48 win 9792 > 230252557> (DF) 0x10 >> 21:52:32.208483 1.34.49.152.ssh > 10.11.15.20.2349: P >> 52257:52449(192) ack 48 win 9792 > 230252557> (DF) 0x10 >>